Event management system with manifest synchronizing feature

ABSTRACT

A system for organizing flight information for passengers attending an event is disclosed. The system includes a memory, a computer display, a synchronization component that maps passenger information from a user format into an application specific format and stores mapped passenger information, and a flight validation component that validates flight information in stored passenger information. The synchronization component scans passenger information in a user format, identifies headers specifying required information, and assign headers to required information that does not have a header. Also disclosed is a computerized method for organizing flight information for passengers attending an event.

RELEVANT APPLICATION

This application claims priority to U.S. Provisional Application Ser.No. 61/136,643, filed Sep. 22, 2008, which is hereby incorporated byreference in its entirety.

TECHNICAL FIELD

This invention is directed towards optimizing the process offorecasting, budgeting, planning and manipulating information used tomanage an event or group movement.

BACKGROUND

An event or group movement includes the forecasting and management of agroup of people that will arrive from numerous domestic and/orinternational locations at various times on various days via commercialflights, private jet aviation, train, bus, car service, or personaltransportation. Upon the arrival of the entire group it is very commonthat corporate events will occur that require the logisticalcoordination of transporting the group to and from each planned event.Once the event has ended each person will require coordination to returnto their destination city; this can take place over a period of days orwithin a few hours on the same day.

One of the problems encountered by the corporate travel and eventmanagement industries with regard to large events is the coordinationand management of the ground transportation and greeting services forthe event. For a large event such as a company meeting or a companyretreat numerous individuals from various geographical locations travelto the city in which the event will take place. In many instances, thereis more than one airport which may service the event location. For eachof these airports there are usually many airline carriers and multipleterminals in which travelers may arrive. In order for greeters to bescheduled to meet travelers at the time of arrival at the gate for theparticular terminal and for travelers to be met by a chauffeur in ascheduled vehicle provided by a ground transportation company, someonemust coordinate and solve the problem of hundreds of travelers arrivingand departing at different terminals at both scheduled and unscheduledtimes. Typically the variables involved with solving this problem arethe particular airport they will arrive or depart from, terminal ofarrival or departure, scheduled time of arrival or departure, any changein scheduled flight time, number of individuals arriving at or departingfrom a particular terminal during that particular time period, and thenumber of travelers a greeter or a ground transportation vehicle canaccommodate. With hundreds of travelers, multiple airport arrivals anddepartures at various terminals, flight delays, it is difficult forsomeone to schedule ground transportation vehicles and greeters.

An example of such an event and scenario would be as follows: an eventis located in the Washington, D.C. area, hundreds of travelers would betraveling by air to three different airports (i.e., the BaltimoreWashington Airport, Dulles Airport and National Airport), each of theseairports have multiple terminals for planes to arrive. The groundtransportation which will move the travelers from each of the threeairports to the event location which may be in a hotel in downtownWashington, D.C., could be accomplished with various types of vehiclesincluding sedans, limousines, SUV's, vans, minibuses, and motor coaches.Each of these vehicle types has a different capacity for carryingpassengers. In order to assess which vehicle type would be used for agiven pick-up at a particular terminal at a particular airport thescheduler needs to identify and group passengers that are arriving atapproximately the same time in the same terminal. The scheduling isexasperated by the fact that planes may arrive early or later thanscheduled, and certain vehicle types may be unavailable if stuck intraffic or still handling a previous pick-up. Other variables may alsocomplicate solving the transportation problem such as certain passengersbeing VIPs and requiring separate cars or special vehicles for theirtransportation.

Additional challenges occur when people are arriving and departing atthe same time on scheduled domestic and customs flights that requirecheck in two hours prior to departure and an undetermined amount of timeto go through customs on arrivals.

Similar issues exists with the scheduling of greeters to meet passengerson their arrival at airport terminals and direct passengers to baggageclaims and vehicles. For example, depending upon the number ofpassengers arriving at a particular time in a particular terminal,multiple greeters may be necessary to direct the passengers to theappropriate vehicles for transportation to the event and location.Determining if a flight is arriving as a customs flight will alsocomplicate the process and requires additional scheduling.

Assigning and managing the ground transportation can be considerablycomplex especially if there is a limited fleet of vehicles that arebeing used to transport the passengers. Determining the most efficientor optimal way to assign the vehicles and move the passengers can bedifficult given all the variables that are involved in scheduling.

When a company plans a company event they may have an internal person ordepartment responsible for managing the event, they may outsource theevent to a corporate travel company or utilize the services offered by adestination management company (DMC). These people or departments willbe referred to as the “Travel Manager”. Depending upon the number ofattendees and geographic locations selected the Travel Manager willprovide a rough ballpark estimate of the costs of the event. Typicallyground transportation services are estimated as a percentage of thetotal cost for the event. e.g., 10%. Sometimes, the groundtransportation service costs are estimated based upon the groundtransportation cost for a prior event or an event which occurred in aprior year. A detailed calculation of the actual cost of the groundtransportation is not typically done because it requires too many hoursof manual labor by the Travel Manager.

Once the decision to have an event is made, the planning generallyprogresses to the next step, and the company event's person willgenerate a manifest of passenger attendees along with information aboutarrival and departure times and airlines for those passengers as well asany activities, events or dine-arounds that will require transportingthe group during the event days. This manifest list is provided to theTravel Manager for their use in estimating the cost of the groundtransportation. Upon receipt of the manifest the Travel Manager willtypically begin a very labor intensive process of reformatting thespreadsheet to identify what days and times people are scheduled toarrive and depart and from what airport and terminal and begin a verycrude grouping or assignment of passengers to vehicles. This processusually takes at least several hours and does not verify or validateinformation or account for any changes. Once the travel manager hascompleted the initial forecasted manifest, the travel manager willforward it to the local ground transportation provider which will thenestimate the ground transportation costs. Typically this is a very roughcost and does not account for invalid information, changes, or optimizedgrouping calculations. Due to the overwhelming amount of changes andgrouping variations it is very common that the quote is completelydifferent than the actual cost. This can result in a lost opportunity towin the business or illustrate the opportunity to optimize the groupingsand decrease ground transportation cost.

In addition to the ground transportation portion of the eventmanagement, the hotels involved in the event management do not havedetailed information about arrival time of guests at the hotel or checkout times for guests departing from the hotel.

Organizing the movement of passengers from one location to another is acomplicated, time-consuming and error-prone process. There are manyinstruction manuals, help guides, books, time management software andseminars that provide event planning guidance. However, these toolsamount to little more than common sense organizational techniques and alaundry list of “to-do” checklists.

There is a strong need to have an event management system for automatingthe repetitive and labor-intensive parts of the event managementprocess, validating, verifying and automatically correcting passengerinformation, providing real-time pricing for rapid invoice forecasting,and automating grouping of passengers into vehicles based upon amultitude of user and system defined factors. A system for allowingbetter scheduling of ground transportation and providing hotels withbetter information of travelers arrival times is needed.

SUMMARY

A computerized method for organizing flight information for passengersattending an event is disclosed. The method includes receiving, in acomputer, a file containing passenger information concerning one or morepassengers, scanning the file for headers specifying requiredinformation, the required information includes passenger name and flightinformation, if headers specifying required information are identified,allowing manual editing of the passenger information, and storingpassenger information in a memory, if one or more headers specifyingrequired information are not identified, providing a user interface on acomputer display that allows a user to manually enter required headerinformation, processing the file, allowing manual editing of thepassenger information, and storing the passenger information in thememory, and validating flight information in the stored passengerinformation.

Also disclosed is a system for organizing flight information forpassengers attending an event. The system includes a memory, a computerdisplay, a synchronization component that maps passenger informationfrom a user format into an application specific format and stores mappedpassenger information in the memory, wherein said synchronizationcomponent scans passenger information in a user format, identifiesheaders specifying required information, and assigns headers to requiredinformation that does not have a header, and wherein the requiredinformation includes passenger name and flight information, a flightvalidation component that validates flight information in the storedpassenger information, and a data visualization component that generatesa visual display of passenger information.

Also disclosed is a computer program product for organizing flightinformation for passengers attending an event. The computer programproduct includes a computer readable medium and computer readable codeembodied on the computer readable medium for organizing flightinformation for passengers attending an event. The computer readablecode includes computer readable program code devices configured toenable a synchronization process to map passenger information from auser format into an application specific format and stores mappedpassenger information, and computer readable program code devicesconfigured to enable a process to validate flight information in storedpassenger information. The synchronization process includes scanningpassenger information in the user format, identifying headers specifyingrequired information, and assigning headers to required information thatdoes not have a header. The required information includes passenger nameand flight information.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a hardware diagram of an embodiment of an event managementsystem.

FIG. 1B is a hardware diagram of another embodiment of an eventmanagement system.

FIG. 2 is a software diagram of one embodiment of the event managementsystem.

FIG. 3A is a flowchart of the manifest synchronization process.

FIG. 3B is an exemplary screen shot showing an uploaded manifest with noheaders

FIG. 3C is an exemplary screen shot showing the mapping of the full namecolumn.

FIG. 3D is an exemplary screen shot showing the mapping of the arrivalairport column.

FIG. 3E is an exemplary screen shot showing the mapping of the arrivalflight number column.

FIG. 3F is an exemplary screen shot showing the mapping of the arrivaldate and time columns.

FIG. 3G is an exemplary screen shot showing a completely mappedmanifest.

FIG. 3H is an exemplary screen shot showing how to manually update amanifest.

FIG. 4A is a flowchart for the group scheduling program.

FIG. 4B is a flowchart showing alternative options available for thegroup scheduling program.

FIG. 4C is another flowchart showing alternative options available forthe group scheduling program.

FIG. 4D is a flowchart for an embodiment of the vehicle type groupscheduling algorithm.

FIG. 4E is a flowchart showing another embodiment of the vehicle typegroup scheduling algorithm.

FIG. 4F shows an exemplary screen shot of an user interface page of thegroup scheduling program.

FIG. 4G shows exemplary parameter settings for arrival passengergrouping and departure passenger grouping.

FIG. 4H shows a screen shot for vehicle management.

FIGS. 5A-5B show an example of sequences for the event managementsystem.

FIGS. 6A-6I are screen shots of an embodiment of the event managementsystem.

FIGS. 7A-7I are screen shots of another embodiment of the eventmanagement system.

DETAILED DESCRIPTION

An event management system that optimizes passenger manifests for use bydestination management, event planning, livery and other types oftransportation companies is described herein. The event managementsystem allows users to effectively plan, analyze, design, forecast, andmodify all types of groups and events and substantially reduces the timeplanners spend manipulating manifests for both budgeting and groundtransportation optimization. The event management system will allowplanners to reduce the time they spend on generating manifests by asmuch as 90%. The saving in time alone will allow the user to focus theirattention on other aspects of the meeting. Event planning mistakes willbe substantially reduced during multilevel manifest manipulation. Inaddition to the time savings, the event management system will catch andcorrect mistakes from the onset within a given manifest also, and checkflights instantaneously without visits to multiple airline websites.

The event management system can be a local system, a web-based system ora hybrid system. These systems will generally have one or moreprocessors and one or more memory devices. In an embodiment, the eventmanagement system comprises software programs that resides locally in acomputer. The software is supported by a web-based database and webservice calls. The software program is designed to upload a raw manifestand allow the user to manipulate the data based on multiple criteria.Planners can use the solution for budgeting and estimating. End userscan select vehicle types and number of passengers while pricing andmanipulating the criteria to fit their specific requirements. VIPs canbe identified and handled according their special needs.

The event management system lowers transportation costs by optimizingtransportation expenses through grouping attendees based on multiplecriteria. The event management system allows users to set budgets inreal-time, without relying on estimates,

FIG. 1A shows the hardware components of an embodiment of a hybrid eventmanagement system 100. In this embodiment, the hardware componentsinclude: client terminals 111, a web application server 112, and adatabase server 113. Each client terminal 111 houses a clientapplication software that include the application code, business logic,and business rules that run and govern the client terminal 111. Eachclient terminal 111 also include a client interface 114 from which therequests for application services are originated. The client terminals111 can take on a variety of forms including desktop PC, a laptop, PDA,blackberry, cell phones, and other portable devices. The web applicationserver 112 provides web services, such as integration with FlightView®or other flight system to ascertain accurate flight information as wellas integration with Microsoft Virtual Earth to identify accurate addresslook ups and mileage and distance between hotels and airports thatsupport the event management system 100 and supplies security for theEvent Management System 100. The database server 113 houses the mappedpassenger manifest data and a database containing the flight informationfrom the various airlines in order to verify and update the accuracy ofthe flight information for each passenger. Flight information is updatedperiodically through web service calls and the updated flightinformation is then stored in the database.

FIG. 1B shows the hardware components of an embodiment of a web-basedevent management system 100′. The hardware components include, but arenot limited to, a database server 115, a groups application server 116,a web server 117, a proxy server 118, the Internet 119 and displayterminals 120. In this embodiment, the database server 115 houses themapped passenger manifest data. The groups application server 116 housesthe software for event management tools, which include application code,business logic, and business rules that run and govern the groupsapplication server 116. The web server 117 and proxy server 118 supportthe event management system 100′ and supply security for the eventmanagement system 100′ and access to the Internet 119. The Internet 119is used for a variety of functions including the auto validation featurewhich requires accessing of a database containing the flight informationfrom the various airlines in order to verify and update the accuracy ofthe flight information for each passenger. The display terminals 120 arewhere the requests for application services originate. The displayterminals 120 can take on a variety of forms including desktop PC, alaptop, PDA, blackberry, cell phones, and other computers and portabledevices.

FIG. 2 depicts software 200 involved in one embodiment of the eventmanagement system 100. The primary components in this embodiment of thesoftware 200 include, but are not limited to: manifest builder program210, manifest synchronization program 211, flight check program 212,event management program 213, group scheduling program 214, passengermanagement program 215, vehicle management program 216, staff managementprogram 217, shuttle program 218, terminal logic program 219, pricingprogram 220, budget and forecasting program 221, invoicing program 222,data visualization program 223, and versioning program 224.

The Manifest Builder Program

The manifest builder program 210 provides the ability to manage theevent from the inception. Gathering the information for all participantsof a group movement is very time consuming, frustrating, and typicallydelivers a result that has many challenges with the integrity andaccuracy of the data. When a user elects to utilize the event managementsystem 100, the user may create a distribution or e-mail list. Onefeature of the manifest builder program 210 will automatically send outa customized email template that is designed to be sent back from eachparticipant accompanied with their entire travel arrangements. Thisinformation may contain flight information and data that goes far beyondthe ground transportation requirements, such as the length of hotelstay, activity selection, meal selection, etc. The manifest builderprogram 210 has a user interface that allows a group coordinator to viewhow many people were sent the request for information or e-mailtemplate, how many people read the email, how many people responded, howmany people had any missing information, etc. The information collectedwill be in a desired format (e.g., as excel files) for processing by theevent management system 100.\

The Manifest Synchronization Program

The manifest synchronization program 211 allows a user to synchronize apassenger manifest with the Event Management System 100, i.e., to map apassenger manifest into the Event Management System 100. This programincludes some automatic correction and compatibility features. Theprogram allows the user to use a new or existing “map” that defines howthe system should import a variety of column-structured manifest fileformats (e.g., Excel formatted files), associate the columns of thatfile to the fields in the system, and perform a number of preprocessingactions on the passenger data. The preprocessing actions may includechanging the case of the names, automatically correcting airline names,verifying that all of the required data is present for each passenger,removing suffixes, prefixes, middle names, adjusting dates and times tostart date of event, randomizing times for forecasting purposes,automatically create new vehicle types in the “Vehicle ManagementProgram” and adding saved maps to templates that can be shared withother users.

Referring now to FIG. 3A, shown is an embodiment of a manifestsynchronization program 211 for the event management system 100.Briefly, the manifest synchronization program 211 processes the requireddata (i.e., first name, last Name, arrival date, arrival time, arrivalairport, arrival airline, arrival flight number, departure date,departure time, departure airport, departure airline and departureflight number, etc.) in a manifest. If any of the required informationis not provided or invalid, the program will not be able to proceed tothe following step without addressing the challenges. The program autodetects each of the above mentioned criteria by mapping each respectivedata set from the original manifest and qualifying the data to allow theuser to proceed to the next step.

As shown in FIG. 3A, the first step of the synchronization process is toupload (subroutine 301) a manifest that is created either inside (e.g.,by the manifest builder program 210) or outside the event managementsystem 100 (e.g., by a passenger or Travel Manager holding the event).In this embodiment, the required data to process a manifest is FirstName, Last Name, Date, Time, Airport, Airline, and Flight #. If there isno manifest to begin from then the data will have to be manuallyentered. The manifest would normally take the form of a detailedpassenger manifest and may be in a variety of computer formats includingexcel spreadsheets and word documents. In a preferred embodiment, themanifest is a spread sheet created in Excel.

Once uploaded, the program will initiate synchronization (subroutine302) to map the passenger manifest into the event management system 100.The program will parse column headers of the manifest (subroutine 303).The headers are first scanned to match the names, if that does not work,then the system will determine the suggested correct column from theheaders and cell data. If headers are recognized (subroutine 304), theprogram will allow the user to modify the data in the manifest(subroutine 305). The data is then serialized to passenger objects(subroutine 306) and used by other programs for a variety of purposes,such as flight check, grouping and reporting (subroutine 307). If noheaders are recognized, the program will perform a header scan in theuploaded manifest (subroutine 308) If the headers are recognized by theheader scan (subroutine 309), the program will proceed to subroutine 305and offer the user an opportunity to modify the manifest. If no headersare recognized by the header scan, the program will perform a moreextensive header and row data scan (subroutine 310). If the headers arerecognized by the header and row data scan (subroutine 311), the programwill again proceed to block 305 and offer the user an opportunity tomodify the manifest. If no headers are recognized by the header and rowdata scan, the program will request the user to manually assign a headerto each columns (subroutine 312). The program will then proceed tosubroutine 305 and the data is serialized to passenger objects(subroutine 306) and used by other programs for a variety of purposes,such as flight check, grouping and reporting (subroutine 307). Until thedata is serialized, it is in a temporary status that will be reassignedfrom the cells of the excel spreadsheet to the object in the system.

FIG. 3B shows an exemplary screen shot where an uploaded manifest has noheaders. The manifest synchronization program 211 will not be able tointuitively suggest the mapping of each column to the required data forFirst Name, Last Name, Date, Time, Airport, Airline and Flight Number.When attempting to parse the headers and no headers 313 are recognized,the manifest synchronization program 211 will mark the required datafields with an X 314. The manifest synchronization program 211, however,will allow a user to manually map each column of the manifest into thesystem by assign a pre-determined header to each column.

FIGS. 3C-3E are screen shots showing how to map the data columns in themanifest of FIG. 3B into the event management system 100. FIG. 3C showsthe mapping of the passenger names. One of the synchronizationrequirements is to have a First Name and a Last Name. The eventmanagement system 100 will accept the data in various formats such asFirst, Last Name or Last, First Name in the same column and separated byvarious characters as a slash, a back slash, a space, a comma, etc. Inthe screen shot shown in FIG. 3C, names in the manifest appear in asingle column 315 as the full name in the format of Last name/FirstName. By selecting the appropriate column on the right hand side of thescreen and selecting the appropriate radio button (i.e., the “Full Name”button 316) in the upper left quadrant, the system will map theappropriate column.

FIG. 3D shows the mapping of arrival airport. By selecting theappropriate manifest column 317 indicating the arrival airport (i.e.,column 2) and mapping the column to the airport button 318 in theArrival section of the user interface on the upper left quadrant of thescreen, the system will accept the information in column 2 of themanifest as the arrival airport.

FIG. 3E shows the mapping of flight number. By selecting the appropriatemanifest column 319 indicating the flight number (i.e., column 5) andmapping the column to Ft# button 320 in the Arrival section of the userinterface on the upper left quadrant of the screen, the system willaccept the information in column 5 of the manifest as the arrival flightnumber.

The manifest synchronization program 211 also allows two or more columnsto be mapped together. As shown in FIG. 3F, the arrival date column 321(i.e., column 6) and arrival time column 322 (i.e., column 7) of themanifest may be jointly mapped to the Date/Time button 323 in theArrival section of the user interface on the upper left quadrant of thescreen. Alternatively, the arrival date column and arrival time columnof the manifest may be separately mapped to the Date button 324 and theTime button 325, respectively, in the Arrival section of the userinterface.

All other required criteria in a manifest may be mapped similarly. Asshown in FIG. 3G, once each criteria has been met, a check mark 326 willappear in each criteria indicating that the user may go to the next stepand sync the passengers.

The manifest synchronization program 211 may allow an override for eachcriteria except for the first and last names, as they need to bedifferent to separate passengers. By selecting the check mark to theright of the required information the system will provide you with theability to set a default override for the entire manifest. In theexample shown in FIG. 3H, a user may click on the check mark of “Date”327 and pull up a calendar 328 to change the date of arrival foreveryone in the manifest and update the manifest with the newinformation.

In certain embodiments, the manifest synchronization program 211 furthercontains an auto guessing component that is capable of fill missing datain passenger information, a faulty data detection and correctioncomponent that detects and corrects faulty data in passengerinformation, and/or a gender identification component that identifiespassenger gender based on passenger name. In one embodiment, the faultydata detection and correction component further comprises a linguisticcomponent to identify and offer options to correct errors in the data.

In other embodiments, the manifest synchronization program 211 is alsocapable of converting airline names to airline codes and/or mapping apassenger type, wherein one of the passengers types is VIP.

In addition to the manual mapping process described above, various otheroptions are available to map the data that is required, as well as datathat is not required but critical to a particular manifest. In someembodiments no manual steps or processes are performed during thesynchronizing process. Once the manifest has been successfullysynchronized with the event management system 100, the passenger datawill be stored in an event management system database and will beautomatically updated by the flight check program 212.

The Flight Check Program

The flight check program 212 has the ability to cross reference eachflight number from each respective airline and airport to ensureaccuracy of the data. In certain embodiments, the flight check program212 makes a call to one or more computer systems over the internet toobtain flight information including flight schedule arrival time, flightstatus, any changes in flight arrival time, and arrival airportterminal. In one embodiment, the flight check program 212 has theability to cross reference each flight number from each respectiveairline and airport with FlightView®.

In certain embodiments, the flight check program 212 has the ability toconfirm that a flight number is in agreement with the correspondingairline listed in the passenger information and/or to confirm that aflight number is in agreement with the corresponding arrival ordeparture time listed in the passenger information. If a mismatch isdetected the flight information for a passenger, the flight checkprogram 212 will examine the rest of the flight information to determinewhich data is in error and correct the error if possible. For example,if the listed arrival airline does not have the listed arrival flightnumber for passenger A, the flight check program 212 will check thearrival time and arrival airport to determine which data (arrivalairline or arrival flight number) is in error. If all other flightinformation (e.g., arrival time and arrival airport) is in agreementwith the listed flight number, the flight check program 212 will assumethat the listed airline is in error and replace the listed airline withthe correct airline. If the flight check program 212 cannot decide whichdata is correct, it will highlight the data in question and request auser to correct the error.

In another embodiment, the flight check program 212 has the ability todetermine airport terminal information based on flight number andairline. The airport terminal information may be initially determinedbased on historic information (e.g., Continental flight number CO482usually arrives at terminal B of Washington Dulles Airport) and thenupdate if new information becomes available.

The flight check program 212 allows notification to be set for anythingthat does not match up entirely to time threshold. A user can set thesethresholds to only indicate the flights that do not match up within thatset time frame. The flight check program 212 has the ability to have anend user correct individual flights as well as the option to save oneflight and have the system auto correct everyone else on that flight.When the end user has missing information or does not know the flight,the flight check program 212 provides the ability to search for flightsand display options to allow the end user to get the information withoutleaving the event management system 100.

In one embodiment, the flight check program 212 uses an algorithm thatseparates the data based on an initial scan for all flights arriving ordeparting on the same date, then the same airport, then the sameairline, then the same flight number. Once each individual flight ischecked, the flight check program 212 generates a report and displaysall passengers on each respective flight for each day. In certainembodiments, the flight check program 212 operates automatically tocheck flight status and update the flight information periodically. Inother embodiments, the flight check program 212 operates based on userrequest. The flight check program 212 may also highlights to userspassenger flights that have been changed by the flight check program 212based on updated flight information, and stores the date and time of thelast flight check for a particular passenger manifest. In oneembodiment, the flight check program 212 further comprises an airportterminal assignment component that assigns passengers to airportterminals and verifies airport terminal data.

The Event Management Program

The event management program 213 provides for user log in and allows theuser to access, delete, and modify existing events, create new events,or create sample scenario events. The Event Management Program 213 isthe enclosing interface of all the group applications from which all ofthe other components are accessed. The event management program 213 isdesigned to be able to manage the event from the planning stage to theactual first day of arrivals, and to the last day of departures. Theevent management program 213 is able to update the information from thefield, remotely, or locally to track, update and monitor the status foreach passenger and each job. Upon the completion of the event, the eventmanagement program 213 will generate an invoice and complete theprocess. In one embodiment, the event management program 213 contains acomponent for creating new events and a component for managing storedevents.

With the never-ending changes, additions and cancellations that occur inreal time during a group movement the system will allow for the user toconstantly re-run the flight checks and groupings to anticipate thechanges and reconfigure the new data to an optimized output. With theability to manage form the field or remotely it is very common that whensomeone has made a change or a cancellation it is overlooked and avehicle is still reserved, with real time updates it minimizes theerrors and streamlines the communication to trigger an event log forevery change identifying who made the change and access to view thehistory to identify why it was done. Having this ability contains thecost for reserving unnecessary vehicles or over/under capacity ofresources as well as accounting for each passenger and each vehicle.

The Group Scheduling Program

The group scheduling program 214 allows a user to configure vehicles andvehicle types, and execute a schedule solving routine to generate groupswhich can then be displayed. The program allows the user to create,modify and delete groups. A group represents a single vehicle thatcarries a specified number of passengers. The user can optionally usethe system's “Solver” which create the groupings for all of thepassengers automatically based upon their flight arrival times,passenger preferences, vehicle preferences, and vehicle capacities. TheSolver's groupings can either be 100% automatic or can be used to assistthe user in creating their own groupings.

FIG. 4A is a flow-chart of the group scheduling program 214 thatprovides an overview of the various routines in the group schedulingprogram 213. In particular, FIG. 4A shows that various subroutines maybe used to achieve the desired grouping solution prior to display. Afterthe initiation of the group scheduling program 213 (subroutine 401), thegroup scheduling program 213 allows the selection of a pick-up window oftime, vehicle capacity, vehicle types and VIP Program (subroutine 402).After these various parameters are set, the program then executes agroup scheduling solver routine which provides solutions to the userbased on the entered parameters (subroutine 403). The result of this isa grouping of passengers for pick up by certain vehicle types at airportterminals. The group scheduling program 213 provides optimization fortypes of vehicles and allows for VIP scheduling. This program providesthe routine then displays the solution (subroutine 404). The user mayeither save the groupings (subroutine 405) and return to the main pageof the program (subroutine 406), or return to the configuring subroutine402 to change variables and re-execute the group schedule solver routineuntil a suitable solution is reached. Also, the routine allows for theuser to update the groups, make changes to the groups, and createdifferent groups (subroutine 407). The updated groupings may be saved(subroutine 405) or reconfigured (subroutine 402) until satisfactorygroupings are achieved.

FIG. 4B shows a flow-chart of the group scheduling program 214 ingreater detail than FIG. 4A. In the particular embodiment shown in FIG.4B, the first decision is whether a VIP option is selected or not (408).If the VIP option has been selected then the passengers are divided upinto VIP type passengers and regular or non-VIP passengers (409). Ifthere are VIP type passengers then the program allows the user to select(410) whether the VIP passengers can be grouped together into singlevehicles (411) or whether each VIP will be afforded his own individualvehicle (412). It is also possible for the user to group certain VIPpassengers while leaving other VIP passengers selected to ride inindividual vehicles. So therefore, even amongst VIP passengers a usercan distinguish between VIP passengers entitled to separate vehicles andthose that may be grouped with other VIPs and share a vehicle. In oneembodiment, the group scheduling program 214 will now group and schedulethe VIPs in either separate or grouped vehicles and optimized by vehicletype (413-416).

In another embodiment, the VIP passengers are handled separately andgenerally prior to the non-VIP passengers in order to allow for the mostcustomization and best vehicles and timing of vehicles to be provided tothe VIPs. In this way the VIP waiting time should be minimized even ifthe fleet's size is not sufficient to accommodate the shortest waitingtimes for all attendees.

Regular passengers are then handled by the group scheduling program 214.Passengers may be scheduled in an efficient and optimal way or may beplaced into designed vehicle type or combination of both. This isinitially determined by decision tree (417). Afterwards passengers andtheir groupings are optimized by vehicle type (418) and schedule (419).If the VIP option is not selected, the group scheduling program 214 willgroup all passengers in a single list (421). The groupings are arrangedand optimized (422) by vehicle type (423) and schedule (424).

The group scheduling program 214 will recursively attempt to group thepassengers within the parameters set of waiting time, vehicle typesavailable, price, etc., until the group scheduling program 214 achieveswhat is considered a best or optimal solution to the grouping problem.Once the VIPs and the non VIPs are grouped and scheduled, theinformation is compiled and prepared for display (subroutine 420).

In certain embodiments, the group scheduling program 214 uses analgorithm that separates the passenger data based on an initial scan forall flights arriving or departing on the same date, then the sameairport, then the same terminal. An initial passenger arrangement willbe created as a pre-group function. With this pre-group, the algorithmwill now look to group these passengers with the time threshold windowindicated and then the smallest vehicle that can accommodate the exactnumber of passengers in the group. Once this grouping function is run,the algorithm will do a sweep and repeat the process. The purpose ofrepeating this routine is to ensure that all passengers have beenassigned to a vehicle. For example, if the system groups 30 people thatwould be grouped in a vehicle and the parameters set by the user statethat the largest vehicle is a vehicle with a capacity of 25 people, thefirst 25 people based on alphabetical order will be assigned to thisvehicle. The 5 passengers that were not assigned will then be assignedto a vehicle that had remaining capacity. If nothing is available, the 5passengers will then be assigned to the smallest vehicle that is capableof handling the group.

In one embodiment, the group scheduling program 214 uses an algorithmthat contains the steps of (a) allowing for the setting of parametersincluding time windows, available vehicle types, and number ofpassengers allocated for vehicle type; (b) assigning passengers arrivingor departing in a specified time window to a time group; (c) assigningpassengers within the time group to one or more terminal groups basedupon expected arrival or departure airport terminal for each passenger;(d) counting a number of terminal groups; (e) setting a terminal groupcounter to one; (f) incrementing and storing the terminal group counterin a memory; (g) if the terminal group counter exceeds the number ofterminal groups go to step (j); (h) defining one of the one or moreterminal groups whose passengers are unassigned to a vehicle type as atemporary group; (i) determining, using a computer, if any one of theavailable vehicle types will accommodate all passengers in the temporarygroup, if so, (u) choosing an available vehicle type that willaccommodate all passengers in the temporary group and has least numberof passengers allocated for vehicle type, (v) assigning the passengersin the temporary group to the chosen vehicle type, and (w) returning tostep (f), if not, (x) assigning as many passengers from the temporarygroup to the available vehicle type that accommodates highest number ofpassengers based upon the number of passengers allocated for vehicletype, (y) redefine the temporary group as those passengers that remainunassigned to a vehicle type, (z) repeat step (i); (j) repeat steps (b)through (i) for time windows with passengers; and (k) displayingpassenger assignment on a computer display.

The step (x) may further comprises the sub-steps of creating a flightgroup by assigning passengers, in the temporary group, on the sameflight to a flight group and assigning as many passengers in the flightgroup as possible to a the available vehicle type. The algorithm mayfurther allow a user to define the VIP status of each passenger at auser interface for setting parameters and assigns vehicles first to VIPpassengers.

In another embodiment, the group scheduling program 214 uses analgorithm that contains the steps of (a) allowing for the setting ofparameters including time windows, available vehicle types, and numberof passengers allocated for vehicle type; (b) assigning passengers toflight groups wherein all passengers on a certain flight are in a flightgroup; (c) repeating steps below using a computer until all passengersare assigned; (d) defining a temporary group as a flight group; (e) forthe temporary group, determining if number of passengers in thetemporary group exceeds highest number of passengers allocated for anyvehicle type, if so go to step (h); (f) for the temporary group,determining if there are any flight groups using a terminal that is asame terminal as the temporary group and having a flight that is withinthe time window, if there are no such flight groups go to step (h); (g)redefining the temporary group by combining the temporary group with aflight group that is at the same terminal and has closest flight time orclosest median flight time to the temporary group, and go to step (e);(h) determining, using a computer, if any one of the available vehicletypes will accommodate all passengers in the temporary group, if so, (u)choosing an available vehicle type that will accommodate all passengersin the temporary group and has lowest of the number of passengersallocated for vehicle type, (v) assigning the passengers in thetemporary group to the chosen vehicle type, and (w) returning to step(c), if not, (x) assigning as many passengers from the temporary groupto the available vehicle type that accommodates highest number ofpassengers based upon the number of passengers allocated for vehicletype, (y) redefine the temporary group as those passengers that remainunassigned to a vehicle type, (z) repeat step (e); and (k) displayingresults of passenger assignments on a computer display. The algorithmmay further allow a user to define the VIP status of each passenger at auser interface for setting parameters and assigns vehicles first to VIPpassengers.

FIG. 4C shows another embodiment of a grouping process. At the outset,the user selects parameters for grouping algorithms (425). The programbegins grouping using the selected parameters (426). All the passengersare separated into VIP and non-VIP categories (427). The VIP passengersare grouped first (428). Briefly, the largest number of passengers thathave not already been grouped for an event type (e.g., arrival ordeparture) with a specified time window on the same date are placed intemporary groups (430). The temporary groups are subdivided based uponthe arrival or departure airport (431). The subdivided temporary groupsare further divided based on the arrival or departure terminal (432).For each subgroup, the program then selects the smallest vehicle thatcan hold all passengers in the group (subroutine 433). The program thenreturns to subroutine 430 to deal with the next largest number ofpassengers that have not already been grouped for an event type with aspecified time window on the same date until all VIP passengers aregrouped (435). The non-VIP passengers are grouped (429) after the VIPpassengers in the same manner. If the number of passengers in thesubgroup exceeds the passenger capacity of the largest vehicle that isavailable, the group scheduling program 214 will assign the maximumallowed number of passengers to the available vehicle (e.g., based onalphabetical order of the last name of the passenger) and send theremaining unassigned passengers back to subroutine 430 for regrouping(434). The system will prioritize which passengers to assign to theavailable vehicle. The system may be programmed to prioritize thepassengers in a number of ways including by flight, by arrival time, byalphabetical order based on last name, by employee types or randomprioritizing.

After all passengers are assigned to groups, the program calculates aprice for the grouping (436) and displays the grouping and price (437).The pricing is calculated based a base rate or a corporate rate, if any.The user has the option to override pricing for each group.

FIG. 4D shows the vehicle type selection component of the groupscheduling program 214 in greater detail than FIG. 4B. In the particularembodiment shown in FIG. 4D, the first decision is to segment thepassengers by date of arrival as shown in “Segment Passengers By Date”438. Once the passengers are segmented by date, then each date segmentis re-segmented by airport as shown in “Segment Passengers By Airport”439. Once the passengers are segmented by airport, then each airportsegment is re-segmented by pickup time window unit intervals as shown in“Segment Passengers By Pickup Time Window” subroutine 440. Once thepassengers are segmented by pickup time window unit intervals, then eachdate segment is re-segmented by terminal as shown in “Segment PassengersBy Terminal” subroutine 441. Once the passengers are segmented byterminal, then each terminal segment is re-segmented by vehicle type asshown in “Segment Passengers By Vehicle Type” subroutine 442. Once thepassengers are segmented by vehicle type, a decision point is reached asshown in “All Segments Processed” subroutine 443. If all passengers havebeen successfully processed, meaning every passenger has been assignedto a group, then the list of groups are saved and the user is returnedto the main program as shown in “Return Groups” subroutine 444. If not,a new group is created as shown in “Create a New Group” subroutine 446.If the segment has no passengers, the system proceeds to the nextsegment as shown in “Move To Next Segment” subroutine 445. If thesegment does have passengers as shown in “Segment Has Passengers”subroutine 447, then the program selects the largest vehicle to fit thenumber of passenger's in that segment as shown in “Biggest Vehicle Fit”subroutine 448. Once the system selects a vehicle type, then a decisionpoint is reached as shown in “Fill Up Vehicle” subroutine 449. If themaximum vehicle capacity for the given vehicle type has been reached,then a new group is created as shown in “Create a New Group” subroutine450 and a passenger is added to that group as shown in “Add Passenger ToGroup” subroutine 451. If the maximum vehicle capacity has not beenreached, then a passenger is added to the group as shown in AddPassenger To Group subroutine 451. After a passenger is added to thegroup as shown in Add Passenger To Group subroutine 451 that passengeris removed from the segment as shown in “Remove Passenger From Segment”subroutine 452. In the Remove Passenger From Segment subroutine, theprogram checks if additional passengers exist in the segment as shown in“Segment Has Passengers” subroutine 447. Once all passengers areallocated to groups, control is returned to the main “Groups Program” asshown in “Return Groups” 444.

Many methods of grouping passengers into cars are available. The goal istypically to group all passengers on same flight along with passengersarriving on flights at the same terminal within a time segment.

FIG. 4E shows an embodiment of a “What If Analyzer” component of thegroup scheduling program 214. In the particular embodiment shown in FIG.4E, the user specifies the destination address of the event, estimatednumber of passengers, estimated arrival airports, and a budget for theevent as shown in “Event Details” subroutine 453. Upon entry of eventdetails, the What If Analyzer subroutine as shown in 454 is initiatedand the system executes the “Create Set Of Segments For Each BusinessRule” subroutine 455. Once passengers are allocated into segments basedupon business rules, passengers are re-segmented based upon terminals asshown in “Terminal Grouping Rules” subroutine 456. Once passengers aresegmented by terminals, passengers are re-segmented by pickup timewindow as shown in “Pickup Time Window Grouping Rules” subroutine 457.Then the system selects an unallocated segment as shown in “SelectUnallocated. Segment” subroutine 458. A loop is reached where the systemcontinually iterates through every possible vehicle capacity, inclusiveof zero capacity, as shown in “Vehicle Capacity Iteration subroutine”459. A vehicle capacity of zero is equivalent to excluding a vehiclefrom the iteration, so once the iterations are complete the system willhave scanned all possible vehicle capacities as well as all possiblevehicle combinations, as shown in Vehicle Capacity Iteration subroutine459. Then the grouping configuration, including all pricing, vehiclecapacities, and other variables associated with the grouping are savedas shown in “Store Grouping Configuration” subroutine 460. A decisionpoint is reached where the system checks if all configurations have beeniterated through as shown in “Segments Complete” subroutine 461. Ifthere are additional segments, the system picks another unallocatedsegment as shown in “Select Unallocated Segment” subroutine 458. Ifthere are no additional segments, the system shows the groupingconfiguration that most closely matches the budget as shown in “DisplaysBest Fit Configuration” subroutine 462. The user then can select a newbudget as shown in “Select New Budget” subroutine 463 and then the useris shown that new configuration as shown in “Displays Best FitConfiguration” subroutine 462. The user can also save the configurationas shown in “Save Configuration” subroutine 464.

Another embodiment of the what if analyzer focuses on flights andattempting to group passengers on the same flight together for greeting,ground transportation, hotel accommodations or other services. This canbe used for departures as well as arrival of attendees. The priority orpreference in this embodiment would be not to break-up into separategroups passengers arriving on the same flight unless it provides asignificant financial advantage. The process would look to keep everyoneon the same flight together in a flight group and add a group ofpassengers to the first flight group whom arrived together on a secondflight in order to increase the size of the first flight group. Incertain embodiments, in certain situations splitting of passenger isallowed to accommodate better pricing of services. The flight preferenceversion of the what if analyzer begins by grouping all passengers whoare on the same flight into separate individual groups, flight groups.In this manner each flight represents a separate group, flight group.The analyzer then process the cost of service (e.g. moving each flightgroup in the most efficient vehicle configuration) and saves that costnumber in memory. Next, the embodiment looks for opportunities to expandeach group beyond a single flight group by combining two flight groups.The system takes each flight group and looks for another flight group inthe same terminal to combine with the first group, e.g. passengers onother flights that arrive at the same terminal. After identifying suchflight groups the system considers combining the two groups therebycreating a larger two flight group. For each combination of flightgroups the system calculates the cost of the service (e.g. movement orground transportation) and stores the cost number. The system theniteratively attempts various combinations of two flight groups, wherefeasible, and calculates service costs until it has exhausted allreasonable possible combinations. The system will consider extended waittimes as unreasonable (greater than a set time limit e.g. 1.5 hours). Itthen attempts combinations of three flight groups and stores the costnumber, followed by four flight groups and so on. When it is complete itwill present the user with some or all of the options calculated and thecost of service for each combination. The user is now free to select anoption for passenger grouping knowing its budgeted cost for therequested service.

In another embodiment, the what if analyzer provides an “Options”function that suggestively offers to a user different options forservice. In particular, it highlights to user different parametersettings or ranges that will dramatically impact the results based onprice, number of vehicles, wait time, etc. When a user groups themanifest and gets a grouping and budget result, the what if analyzerwill thereafter analyze the information and provide feedback toillustrate various alternative options that a user may want to consider.Once the grouping function has delivered results based on the parametersettings indicated by the user, alternative options will be displayed toprovide various cost effective options that may be preferable by theuser. The what if analyzer will take the initial output and based on theinitial algorithms, cross reference the information and identify whatchanges would alter the results to yield a more cost effective solutionor better solution.

In one embodiment, a first option will run an algorithm that will lookto find out at what point changing the time window threshold to agreater amount will deliver a more cost effective solution that willsolve for a 10% reduction in cost. A second option will run an algorithmthat will look to find out at what point changing the vehicle capacitiesto a greater amount will deliver a more cost effective solution thatwill solve for a 10% reduction in cost. A third option will run analgorithm that will look to find out at what point changing each settinga minimal amount to deliver a more cost effective solution that willsolve for a 10% reduction in cost. These options may then be displayedto the user. If any of these options would be preferred, by simplyselecting that option the groupings will be regrouped to accomplish theselected results with the new settings. The what if analyzer will alsohave the ability to adjust the percentage delta you will be looking tochange with the new settings, for example instead of 10% the user maywant to achieve a 20% savings and the what if analyzer will run theoptions to achieve the new desired percentage.

FIG. 4F shows an exemplary screen shot of an user interface page of thegroup scheduling program 214. The Passenger Grouping settings 466 shownin the top left corner of the screen. FIG. 4G shows exemplary parametersettings for arrival passenger grouping 467 and departure passengergrouping 468. The group scheduling program 214 allows passengers to begrouped only when they are on the same flight (box 469) by selecting the“Yes” button 470 in the box 469. Another option is to have passengersbooked on flights arriving within a certain number of minutes. If “No”(button 471) is selected in box 469, the number of minutes desiredbetween flights needs to be entered in box 472 to set the groupingparameter. For a Departure the maximum wait time at the airport minutesthreshold needs to be indicated in box 473 if passengers will not begrouped on the same flight.

Referring again to FIG. 4G, in order to initiate the groupingcomputation, the Refresh Groupings button 474 (see, FIG. 4G) is selectedto generate the groupings. Groupings by VIP status may or may not impacta manifest, if the manifest does not have any VIP's within the data NOaction for VIP's (button 475) may be selected. In the event the manifesthas VIP's, the two options are to group the VIP's together (button 476)or in separate vehicles (button 477). When VIP's are grouped togetherthe grouping parameters are set first and take precedence, thereafter ifVIP's are within a group they are then separated out and grouped in theappropriate vehicle that will accommodate the number of VIP's. WhenVIP's in Separate Vehicles is selected, each VIP will be provided withan individual vehicle regardless of when their flight is arriving ordeparting.

Groupings by Time will depend on the event managing Arrivals orDepartures. For arrivals and departures, the program has the capabilityas mentioned before to group passengers on the same flight only or onflights arriving within a certain number of minutes. The program alsoprovides the ability to shift the pickup window forward for a desirednumber of minutes to account for any wait time by entering the desiredwait time in windows 478 and 479 for domestic and international flights,respectively. For departures the program provides the ability to set anadvanced check in time window for both domestic and internationalflights in windows 480 and 481, respectively.

FIG. 4H shows an exemplary vehicle settings for passenger grouping byvehicle. The vehicle column 482 provide the vehicle type and the maxcolumn 484 shows the maximum number of passengers allowed in each typeof vehicle. Grouping by vehicle can be set in the respective field foreach vehicle. If the vehicle is desired to be grouped, a “Y” is selectedin the Use? column 483 in the row corresponding to the vehicle. Theprogram provides a default passenger setting 485 for each type ofvehicles. The current passenger setting 486 can be changed to have anynumber of passengers up to the maximum capacity shown in column 484.

If a price has been established in the system, the rate willautopopulate underneath each respective airport for the appropriatevehicle in columns 487 and 488, for example. The program has the abilityto store pricing for each respective airport to any zip code. If a priceis not stored or a pricing override is desired, the user may type in therate in the Airport (OV) column 488 to apply the override

Similar subroutines are provided for Grouping by Airport and Grouping byTerminal. Again, the program allows a user to set up various parameters,such as grouping passengers on the same flight, minutes to grouppassengers if grouping separate flights, for arrivals minutes to shiftforward domestic and international pick up times, for departures maximumwait time at the airport, advanced domestic and international minimumcheck in time, set VIP's to be grouped together, separate or not at all,ability to select desired vehicle types, set capacity of vehicles, andset prices for vehicles.

In certain embodiments, the group scheduling program 214 may incorporatea number of additional parameters into its grouping algorithm to furtherimprove the efficiency of passenger grouping and transportation.Examples of additional parameters include, but are not limited to,vehicle passenger load time, vehicle passenger unload time, refuelingtimes, wait time, number of refuels, total number of trips, maximalnumber of loops/rotation, break time, vehicle specific travel time,vehicle luggage capacity, estimated luggage numbers (tied to passengercount), transport zoning requirement, and transport access.

The Passenger Management Program

The passenger management program 215 of this embodiment allows a user todelete, edit, and add passengers assigned to participate in an event.The passenger management program 215 contains a passenger statuscomponent for one of more of the following: changing, adding and editinga status for a passenger. Passengers may be added either manuallythrough the “Add Passengers” feature, or automatically by importing apassenger manifest. passenger management program 215 can also allow thevalidation of flight information and the importing or exporting ofpassenger data to other systems or external software. For example, theuser may instruct the program to validate and automatically correct theflight data for all of the passengers.

Prior to executing passenger management features, the event managementsystem 100 typically has passenger data available. The passenger datamay be stored locally in the client application 111 or display terminal120, or remotely in the database server 113 or 115. This storage is doneas described earlier by the manifest synchronization program 212, whichuploads manifest data, maps the passenger manifest date and thentransforms the passenger manifest data and stores the data in thesystem. In this embodiment when passenger data is edited, or if newpassengers are to be added, the user is allowed to store the passengerdata once the changes have been made and update the passenger list ormanifest for the particular event.

In certain embodiments, the passenger management program 215 may allowthe user to prompt for flight validation and can perform a validation ofall the flights that are stored in the event management system 100 forthe particular passengers of that event.

Finally, the passenger management program 215 allows for exporting thepassenger list into a ground transport dispatch system. Variousbidirectional real time synchronization between the passenger managementprogram 215 and the back-end ground transport management platform mayexist and be supported by the passenger management program 215. In otherembodiments, the passenger management program 215 also allows forexporting of passenger lists to a file or to other outside systems.

The Vehicle Management Program

The vehicle management program 216 allows a user to view the vehiclesinvolved in an event and make changes as appropriate. In particular, itallows the user to edit the vehicle information by creating customvehicle types, defining the capacity of each vehicle and defining theinventory available for each vehicle. In one embodiment the managementof the vehicles involved in an event can be edited and saved with theevent in the event management database. The vehicle management program216 allows the user to enter a rate for each vehicle as well aschanging, editing or eliminating the vehicle rates. By tracking therates the vehicle management program 216 can assist in determining thecost for the ground transportation for a particular event. Normally,various vehicle types are available for any given event, such as sedans,limos, vans, minibuses and motor coaches. Typically each of thesevehicles has different rates and a different capacity to carrypassengers. The same type of vehicle may also have different rates atdifferent locations. In certain embodiments, the vehicle managementprogram 216 maintains a vehicle database that contains all vehiclerelated information, including but is not limited to, vehicle rates,passenger capacity, special vehicle features such as on-board DVDplayer, on-board bar, etc., airport terminal maps and other information.

The Staff Management Program

Staffing is an important consideration in event management planning.Typically, staff includes greeters at the airport, greeters at hotels,greeters at event locations and drivers or chauffeurs. The staffmanagement program 217 allows users to manage the staff assigned toparticular events. In one embodiment the program also assists the userin determining how much staff is needed for an event and where and whento position staff at certain locations for the event. The staffmanagement program 217 allows the user to add additional staff to anevent, edit the current staffing of an event and save thosedeterminations in the event management database. The system also allowsthe user to delete the number of staff or delete particular individualsin the staff from the event.

In one embodiment, based upon the parameters that are entered by theuser, such as whether greeters are desirable at airports and hotels, andhow many passengers a greeter can handle at one time, the staffmanagement program 217 will determine the number of individual staffmembers that are needed to properly staff an event. By automaticallydetermining an appropriate staffing level for an event, the staffmanagement program 217 allows the users to change parameters and changethe staffing levels of the event to accommodate specific needs orbudgets.

The Shuttle Program

The shuttle program 218 allows for special treatment for “Shuttle” or“Hourly Service”. Every user has the ability to group passengers basedon the standard grouping parameters and principles. When the “Shuttle”or “Hourly Service” feature is selected, the user can elect to have theentire manifest grouped with hourly services or the option to optimizethe service and cost based on the system suggesting when the hourlyservice fits best. When the group is managed by hourly services, theshuttle program 218 will take the first arrival or departure of the dayand the last arrival or departure for the day and look at the traveltime between each location, account for any load and unload time, anybreak time and create a solution that provides the rotation of the leastamount of vehicles at the most cost effective price to perform aconstant loop from airport to destination. Once the shuttle program 218provides the output, the user can modify or change the settings untilthe desired output is achieved. When the user elects to have the shuttleprogram 218 optimize the grouping based on a combination of standardgrouping and “Shuttle Service”, the shuttle program 218 will require theuser to determine the least amount of people to be transported within aset time threshold and the shuttle program 218 will calculate when thesuggested times and vehicles shuttle service should be utilized. In thismanner, a hybrid or combination of shuttle and assigned pick-up canoccur.

The Terminal Logic Program

The terminal logic program 219 allows the user to utilize the terminallogic built into the system that displays each airport in the countryand the terminals within each airport. Each Administrative user willhave the ability to override any of the default information and managethe terminal logic as it applies to their particular needs. The terminallogic may include airline assignments for each terminal.

The Pricing Program

The pricing program 220 has the unique ability to import data,specifically pricing and rates for various transportation tools (e.g.,sedans, limousines, SUV's, vans, minibuses, and motor coaches, etc.) andservices (e.g., shuttle services, guided tours, etc.) that can be loadedand stored in the system for purposes of comparative analysis orforecasted budgeting. The pricing program 220 allows pricing from anyairport to any zip code within the United States to be imported into thesystem in a matter of minutes. By default, the pricing program 220 hasrates stored for the entire country that can be accessed within thesystem.

The Budget and Forecasting Program

The budget and forecasting program 221 provides a tool designed tobudget and forecast prospective group movements. The budget andforecasting program 221 may create a non-real event, e.g., a sample,exemplary or dummy event, wherein the non-real event information can beused to forecast, budget, estimate and plan a real event. Utilizinghistorical data, the budget and forecasting program 221 allows a user toidentify the most cost effective place to have an event.

For example, if a user wanted to compare how much it would be to have ameeting in Chicago or Los Angeles, the budget and forecasting program221 would review and analyze historical results that would helpdetermine a projected cost of a group movement.

In one embodiment, the budget and forecasting program 221 is architectedto provide a turkey system solution. The initial phase would be theplanning phase that looks to identify market pricing. This is where auser can determine the best city to plan an event based on current andhistorical pricing and actual previous event history. This process couldinclude airline hotel, ground and other costs. The next step would be toforecast the associated costs of an event once a destination city hasbeen selected. The forecast will take the initial passenger manifest andgroup all passengers in the most cost effective manner with the desiredsettings of the end user. This process can be repeated numerous timeswith all of the additions, changes, and cancellations.

The Invoicing Program

The invoicing program 222 allows users to generate specific invoices forevents that have been processed or to bill advances or bill for futureevents. Various other types of invoices may also be produced with thesystem as needed. Typically in the industries such as conference,transportation, travel, ground transportation, invoices are created withspecific logos and identifications. The invoicing program 222 allows theuser to browse through images that are available either within the eventmanagement system 100 or external to the event management system 100.When an appropriate image is located it may be placed in the logo formatfor use by the system. If the logo is external to the system, theinvoicing program 222 allows the logo to be uploaded and stored in theevent management system 100 either temporarily or on a more permanentbasis. Once a logo is uploaded and available, a user may generate any ofmany types of invoices with the logo. These invoices may be created in avariety of computer formats including an HTML format as well as Excelspreadsheet format or Word format.

The Data Visualization Program

The data visualization program 223 allows a user to view chart-basedgraphical representations of various statistics and customize displaysand charts relating to an event. For example, the data visualizationprogram 223 may offer the ability to display information from eachmanifest in various charts that depict the following: arrivals by timeof day for a single airport or multiple airport; departures from asingle location to a single airport or multiple airports; arrivals ordepartures by the time of day by various combinations of terminal,vehicle, VIP/Non-VIP, airline, flight number, domestic/customs pickupsor drop offs and other information. In order to support these variousdisplay methodologies, the data visualization program 223 allows theuser to enter various parameters and customize the particular displays.

The Versioning Program

The versioning program 224 allows users to save various versions oftheir event plan. Users may create events, edit events, and save variousversions of the event management plan. In this way a user may savealternative event plans for proposal or for other considerations. Once aparticular plan is chosen to be executed, then other versions of theplan may be deleted or simply saved in the system for future referenceby this user or other users.

Computer Program Products

Also disclosed are computer program products that assist in eventmanagement and organize flight information and ground transportation forairline passengers attending the event. One embodiment relates to acomputer program product for assisting in event management. The computerprogram product includes a computer readable medium and computerreadable code embodied on the computer readable medium for eventmanagement. The computer readable code includes computer readableprogram code devices configured to enable a processor to obtaininformation about an event including an event name, a sponsor, and alocation; computer readable program code devices configured to enable aprocessor to convert a passenger manifest from one format to another;computer readable program code devices configured to enable a processorto change the converted passenger manifest; computer readable programcode devices configured to enable a processor to effect a selection ofvehicle types and capacity of vehicles; computer readable program codedevices configured to enable a processor to categorize passengers intogroups and identifying an expected service time by processing flightinformation, the vehicle types, and the vehicle capacity; computerreadable program code devices configured to enable a processor to effectstoring of passenger information and the passenger groups; computerreadable program code devices configured to enable a processor toforecast a budget based on a price for the movement of one or more ofthe vehicle types; and computer readable program code devices configuredto enable a processor to effect the display of the forecast budget andinformation about the event.

In certain embodiments, the computer program product for assisting inevent management may further include computer readable program codedevices configured to enable a processor to manage staffing of theevent, computer readable program code devices configured to enable aprocessor to effect storing of multiple versions of data related to thesame event, and/or computer readable program code devices configured toenable a processor to generate diagram/chart relating to the event forvisual display.

Another embodiment relates to a computer program product for organizingground transportation of airline passengers attending an event. Thecomputer program product contains a computer readable medium andcomputer readable code embodied on the computer readable medium fororganizing ground transportation of airline passengers attending anevent. The computer readable code includes: computer readable programcode devices configured to enable a data entry process that receivespassenger data including names of passengers and flight

information and stores the passenger data in an application specificformat; computer readable program code devices configured to enable agroup scheduling component that allows a user to set parametersincluding VIP status, time windows, vehicle types, and number ofpassengers allocated for vehicle type, and provides passenger groupingsbased on flight information and user-set parameters; and computerreadable program code devices configured to provides a default settingif a parameter is not set by a user, to divides passengers into a VIPgroup and a non-VIP group based on VIP status of passengers, andprocesses the VIP group first.

In certain embodiments, the computer program product for organizingground transportation of airline passengers attending an event mayfurther include computer readable program code devices configured toenable a what-if-analysis process that provides passenger groupings andcost associated with each grouping based on a number of commonly usedparameter settings and/or computer readable program code devicesconfigured to enable a grouping process based on a shuttle service thatruns on a fixed time schedule.

Another embodiment relates to a computer program product for organizingflight information for passengers attending an event. The computerprogram product includes a computer readable medium and computerreadable code embodied on the computer readable medium for organizingflight information for passengers attending an event. The computerreadable code includes: computer readable program code devicesconfigured to enable a synchronization process to map passengerinformation from a user format into an application specific format andstores mapped passenger information; and computer readable program codedevices configured to enable a process to validate flight information instored passenger information. The synchronization process includes:scanning passenger information, in the user format, identifying headersspecifying required information, and assigning headers to requiredinformation that does not have a header. The required informationincludes passenger name and flight information.

EXAMPLES

FIGS. 5A-5B shows an example of one intended utilization of the eventmanagement system 100. Referring now to FIG. 5A, the user starts bylogging into the system as shown in “Login” subroutine 500. If the userdoes not successfully authenticate in “Authentication” subroutine 501,the user is returned to the login as shown in “Authentication”subroutine 501. If the user does successfully authenticate in“Authentication” subroutine 501, the system displays a list of allevents accessible to that user account as shown in “Display Events List”subroutine 502. The user can delete an event as shown in “Delete Event”subroutine 503, after which point the user is returned to the “DisplayEvents List” subroutine 502. The user can also create a new event asshown in “Create A New Event” subroutine 505. After creating a newevent, the system displays the event details tab as shown in “DisplayEvent Details” subroutine 506. The user then enters the details for theevent, such as destination address and primary contact information, asshown in “Enter Event Details” subroutine 507. A user may also edit anexisting event as shown in “Edit Existing Event” subroutine 504. Once auser has entered the event details for a new event as shown in “EnterEvent Details” subroutine 507 or edited an existing event as shown in“Edit Existing Event” subroutine 504, the user is brought to thepassenger tab as shown in “Passenger Tab” subroutine 508. The user mayadd passengers into the system manually as shown in “Add PassengersManually” subroutine 509. Alternatively, the user may upload a manifestcontaining a list of all of the passengers as shown in “Upload PassengerManifest” subroutine 510. The unloaded manifest is then examined by the“Pre-Sync Analysis” subroutine 511. If the manifest is in a formatcompatible with the system, the passengers are imported into the systemas shown in “Import Passengers” subroutine 512. If the manifest is in aformat not compatible with the system, the manifest is synchronized inthe “manual mapping” subroutine 513 and then imported into the system asshown in “Import Passengers” subroutine 512

Referring now to FIG. 5B, whether the user added passengers manually asshown in “Add New Passengers” subroutine 509 or imported the passengersas shown in “Import Passengers” subroutine 512, the passengers are nowadded into the system as shown in “Passengers Added” subroutine 513 andvalidated by the system through the ‘Flight Check” subroutine 514. Theuser now selects an action as shown in “User Selects Action” subroutine515. The user may add, delete or edit passenger information in“Add/Delete/Edit Passengers” subroutine 516. The user may update flightdata in “Update Passenger Flight Data” subroutine 517. The user maystart grouping passengers using the “Groups Scheduling Program”subroutine 519 or, if the passengers have been grouped in a previoussession, automatically and manually manipulate groups for the passengersin “Add/Modify/Delete group” subroutine 518. The user may also add,modify and delete vehicle types, capacities, inventories and pricingrates in “Vehicle Management Program” subroutine 520. The user may add,modify and delete staff allocated for the event in “Staff ManagementProgram” subroutine 521. The user may arrange for shuttle services in“Shuttle Program” subroutine 522. The user may obtain airport terminalinformation using “Terminal Logic Program” subroutine 523. The user mayevaluate the cost of the transportation plan using the “Budget andForecasting Program” subroutine 524. The user may also view and save theinvoice for the event as shown in “Select Invoice Program” subroutine525. The user may also view event statistics as shown in “ViewStatistics” subroutine 526. Finally, the user may save or edit differentversions of the event as shown in “Select Versions Program” subroutine527.

FIGS. 6A-6I are screen shots of an embodiment of an event managementsystem 100. Many different types of screens, screen formats and dataarrangements can be used with the event management system 100. Varioususe and combinations of color, icons and buttons can be applied indifferent embodiments of the event management system 100.

In this embodiment, the event management system 100 is installed on auser computer and is supported by the Web Application Server 112 andDatabase 113 as shown in FIG. 1A. After the installation, the system maybe initialized from an existing program, such as Excel. In oneembodiment, the system is designated as “Manifest Optimization Solution(MOS)” and can be launched by clicking an “MOS” tab in an Excel toolbar. A user may log in the system use a username/password combination.

An event screen will be displayed by the system after login. The usermay select an existing event or a new event. If the login is anadministrative login, the user can see all events from all accounts.Otherwise, the user can see only events associated on his account. Fromthis page the user can delete, create, or edit an event. If the userselected a new event, the screen allows the user to enter and savedetails of the event. Each event is assigned an identification numberfor future reference.

After the event screen, the user can now import a manifest from alocation in the user's computer into the system. The imported manifestwill be subjected to a pre-sync analysis. The user may click on an“OPEN” button in the open Excel sheet, navigate to the location of themanifest the user wish to import, and double click the manifest to loadit into the system.

FIG. 6A shows a screen for performing a pre-sync analysis to verify thatthe manifest contains the data requirements to be processed through thesystem. The pre-sync analysis may be initiated by click on the “Syncing”tab 606 to highlight it. After selecting the Syncing tab 606, the usermay press the “perform pre sync analysis” tab 607 to start the process.The system will guide the user through the data verification process.For example, FIG. 6B shows a manifest with a missing header for arrivalairline. The missing header 608 is indicated be a “-” sign 609 in thecheck list shown on the left side of the screen. To correct the problem,the user may re-assign the column by clicking on the column header 608,and select the correct header 610 (ARRAL) from a pull down list 611(FIG. 6C).

The system will need to validate the following criteria: arriving anddeparting airport, airline, flight number, date and time of the flight,first name and last name. The system will search all the information onthe manifest. A manifest that passes Pre Sync Analysis will have greencheckmarks on all required criteria. If all criteria received a greencheckmark, the system will proceeds to Sync options. The Sync optionsmay include an “Extra Passengers” option to allow attendees to add theguests traveling with them; a “Use Previous Passenger Values” option touse the same information entered for the prior traveler; a “Full Name isLast then First” option for manifests having the passenger's first andlast name in the same cell; a “Convert Airline Names to Codes” option totranslate airline names, i.e. American Airlines to the IATA code of AA;an “Extract Flight number from FN Column” option if the flight number(FN) column has additional non flight number related data in it; and a“Verify Cell Data Now” option to revalidate any data a user havemodified or added.

The Sync options may also include sync manifest options, such as a“Merge Passengers” options that can be used to merge modifications oradditions to a current manifest; a “Replace Passengers” option that canbe used to overwrite the entire passenger list; an “Add Passenger”option that can be used to add a defined list of new passengers to acurrent manifest; and a “Delete Passengers” option that can be used todelete a defined list of passengers a user wish to remove from themanifest.

After the completion of the Pre-Sync process, a user may press the SyncNow button 612 (FIG. 6D) move to the data to the Flight Check process.The user may open an “Event Viewer” window that allows the user toproduce grouping options and publish manifests and budget templates.FIG. 6E shows a “Manage Passenger” sheet that allows a user to edit thespecific passenger details and assign different priority status. Forexample, from the Manage Passenger page a user may navigate to a flightcheck screen by hovering the mouse over the Build Passenger tab 615.This will display a new list of options including a “Check Flights”option. The user may select the “Check Flights” option and set in a“Flight Update Time Window” to an acceptable tolerance that the userwants the system to allow for an adjusted arrival time vs. the clientprovided estimated arrival time.

Once a user has entered the desired time frame into the “Flight UpdateTime Window,” the user may initiate the Flight Check process. Once theflight check is complete, the user may review the Event viewer (FIG. 6F)for any non validated flight issues 619. If issues are identified, theuser may select the “Show/Hide Export Options” 620 to generate aconsolidated list for correction.

The system also allows the user to group passengers using an “AssignPassengers to Vehicle Groups” function. Once in the “Assign Passengersto Vehicle Groups” screen (FIG. 6G), the user may begin the process ofassigning time parameters, vehicles to be utilized, vehicle capacity andpassenger priority. Time window 623 defines the time you are willing tohave passengers wait between groupings. Pickup Time Buffer 624 definesthe time difference between either flight arrival or departure and thetime the travelers are to be scheduled for pick up. The user can movethe time forward for airport pickups and this is particularly useful fordifferentiating the time for Domestic and international arrivals. ForDepartures, the user would determine the amount of time the user want tohave the clients at the airport plus the travel time to the hotel.

FIG. 6H shows a vehicle assignment screen that allows a user to eitherselect the “Use Passenger Vehicle Types” tab 625 (uploaded from theoriginal manifest) or “Optimize By Vehicle Capacity” tab 626. Theselection allows the system to optimize the vehicle selection processand assigning the correct vehicle based on the time parameters andselected vehicle choices. Based on the tone the user wishes to set forthe event, the user can select the appropriate vehicle type by placing acheck mark in the vehicles the user wishes to use. The Unique PassengerGrouping Rules section 627 allows a user to keep all passengers with thesame status, or separate VIPs. The VIPs will be placed in their ownvehicle regardless of flight and arrival time frames.

The system will produce the groupings based upon the user's selections.The user can repeat the process and change the rules until a desiredresult is reached. Once the user achieves a satisfactory result in the“assign passengers to vehicles” process, the user can publish theresults back to the initial spreadsheet as shown in FIG. 6I. The usercan create variations of the report by simply changing the vehicles tobe utilized, the passenger capacity by vehicle and the amount of waittime used for grouping frequency. The user must save the new settingsprior to exporting additional reports. Once the user is satisfied withthe structure of the groupings, the user can forward the report toclients for review.

FIGS. 7A-7H are screen shots of another embodiment of an eventmanagement system 100. Many different types of screens, screen formatsand data arrangements can be used with the event management system.Various use and combinations of color, icons and buttons can be appliedin different embodiments of the event management system.

FIG. 7A shows the first screen displayed by the system after login. Eachscreen after the login screen shows an “Administrative Tools” section701 with links to “Events” 702, “Users” 703, “Airports” 704, and“Airlines” 705. These links lead to screens containing informationregarding the events in the event management system. These links appearon most of the screens in the system in order to provide the user withease of navigation within the system.

The screen shown in FIG. 7A is the “Events” page. After login, a usersees a list of all previously created events as well as any events thatare in the process of being created. If the login is an administrativelogin, the user can see all events from all accounts. Otherwise, theuser can see only events associated on his account. From this page youcan delete, create, or edit an event. In this embodiment, each event isassigned a name, a customer, a start date and an end date. The firstevent shown is called “Medical Advisory Group.” The customer associatedwith this first event is “GEP South Florida.” Each event is assigned astart date and end date, which are also listed on the event screen.

FIG. 7B shows the “Event Information” screen with the “Event Details”tab 706 selected. In this tab, a user may create a new event by awizard-driven process that the user will follow to instantiate an event.The first step in the tab wizard involves filling out all the base eventinformation, such as the location that the event will be held at,contact information, dates, etc. The location is used to estimate traveldistance and time, as well as cost. If the user logged in as anadministrator, the user can see all customer names, otherwise thecustomer name is fixed and cannot be altered except by an administrator.

In particular, in this embodiment, the new event screen allows for entryor assignment of data to an event. Specifically, in this embodiment, auser may enter a customer name, event name, event code, start date, enddate, contact name, contact phone number, event type, default run type,various options, textual description of the event, default vehicle type,and location drop-off. Also, in this embodiment, the location drop-offincludes: location name, street number street name, and cross street.This screen may be used to enter various other information related to ana proposed or actual event.

The “Event Information” screen may be used to upload, add or exportpassenger information. More particularly, once an event is created, anew tab in the wizard appears where the user can upload new passengers.This step typically involves uploading manifest in excel or other formatand mapping the fields in the manifest (e.g., Excel file) to the fieldsin the event management application. The system allows the user tobrowse or select a file to upload, into the event management system.

Various methods exist for mapping (i.e., synchronizing) the manifestdata into the application. The user preferably makes a conversion mapavailable to the system. In one embodiment, the following methods aremade available to the user for providing a map: selecting an “Auto ScanMaps for Match” to have the application try to determine the appropriatemap for the manifest; selecting an existing map that appropriately mapsthe manifest; editing an existing map; or creating a new map. The “AutoScan Maps for Match” routine will scan maps that the system has accessor is aware of in order to find an appropriate map to use for theconversion of the data.

FIG. 7C shows a view of the “Event Information” screen after a passengermanifest has been uploaded and accepted. In this view of the EventInformation screen, shown are various tabs with corresponding screenssuch as, “Event Details” 707, “Passengers” 708, “Groups” 709, “Vehicles”710, “Staff” 711, “Versions” 712, “Generate Invoice” 713, and “ViewStatistics” 714. Shown is the Passengers screen. A notice (in red) willappear indicating that the flight status for the passengers has not beenvalidated. Each passenger's flight status is shown in the “FlightStatus” column. Initially, all status's are set to unknown. Variousportions of these screens can be color coded. On this screen, theunknown status indicator is preferably color coded to highlight the itemfor the user.

Upon selecting “Update Flight Times” 715 on the “Event Information”screen, the passenger flight data will be validated and updated to themost current information from the airlines. A processing circle, clock,hour glass or similar icon may be used to show the user that the flightvalidation program is in process. In use, the flight validation processtakes about 5 seconds to initialize, and then about 1.5 seconds perflight check. After flight validation, the Flight Status column in FIG.7C will change from “unknown” to ‘updated.”

FIG. 7D shows a “Passenger” screen where the user can update passengerinformation. Using this screen, the user may edit a passengersinformation or status. In this example, the user has updated thepassenger's status to VIP 716. Any passenger information entered,converted or uploaded in the event management system may be changed. Inthis embodiment, any one of the passenger parameters shown may bechanged including name, VIP site inspector, priority, vehicle type,airport, terminal, airline, flight number, arrival date, arrival time,flight status and pick-up. The user selects “Update Passenger” on thisscreen and the updates are saved. The user can also alter andrevalidate/update the flight data.

Referring again to FIG. 7C, selection of “Groups” tab 709 allows usersto schedule groups, add new groups, delete groups, and export groups toa spreadsheet program. The user may selects the Groups tab 709 and thenthe “Schedule Groups” within the Groups tab 709 to begin computing thegroups. The computing process involves auto-assigning the passengers togroups. Initially, the passenger vehicle type is used.

FIG. 7E shows a “Group Scheduler” screen that provides a “Pickup Window”section 722 for specifying a pick up time window for each group, a“Vehicle Capacities” section 723 showing sedans, SUVs, Limos, vans,stretch SUVs, mini buses, and motor coaches as the vehicle options, anda “Vehicle Type” section 724. In this embodiment, the “Pickup Window”section 722 contains a sliding bar 720 that allows a user to increase ordecrease the length of the pick up time window by moving the sliding bar720 towards right or left, respectively. The “Vehicle Capacities”section 723 allows the user to specify the number of passengers to beassigned to each type of vehicle. In this embodiment, the ““VehicleCapacities” section 723 also contains a plurality of sliding bars 721that allow a user to increase or decrease the number of passengerassigned to each type of vehicle by moving the sliding bars 721 towardsright or left, respectively. The maximum number of passengers a user mayassign to a vehicle type equals the maximum passenger capacity of thatvehicle type. The screens may also provide a section for “VIP GroupingRules” (not shown) allowing the user to choose between not applying anyrules to the VIP groups or grouping VIPs together or separately. TheVehicle Type section allows the user to select vehicle types that werepreviously designated for a passenger, or choose to optimize by vehiclecapacity, which would automatically select vehicle types based on thenumber of passengers. The screen also shows a “Calculated Groups”section 725. The calculated groups each have designated airports,terminals, passenger lists, and vehicle types. The “Calculated Groups”section may also provide an estimated cost based on the grouping.

The user may change the settings in the “Pickup Window,” the “VehicleCapacities” and/or the “Vehicle Type” section. The changes will beautomatically reflected in the “Calculated Groups” section withrecalculated cost.

FIG. 7F shows the “Event Information” screen with tabs for screensdisplaying event details, passengers, groups, vehicles, staff, versions,invoices, and statistics regarding events. The “Groups” screen is shownwith the option to schedule groups, add new groups, delete groups, orexport groups to a spreadsheet program, such as Excel. The Groups screenalso shows the name of each group, the airport, terminal, vehicle type,passengers, and pickup date/time/and location associated with eachgroup.

FIG. 7G shows the “Event Vehicle” screen with a “Custom Rates” field 727for inserting custom rates for vehicles. The fields in this exampleinclude “Event Name,” “Customer Name,” “Vehicle Name,” “Vehicle Code,”“Inventory,” and “Capacity.” For each vehicle type, a maximum, suggestedand current number of passengers is given. Selecting the “UpdateVehicle” tab 729, the user can update the vehicles to alter defaultcapacities, insert custom rates, and alter vehicle names. In thisexample, no custom rates have been entered. The “Add Rate” section 728allows users to add the rate for a vehicle in an event based on specificairports. This screen also allows the user update the vehicle or go backto an event via links.

FIG. 7H shows the “Event Information” screen with the “Groups” tabselected. The Groups tab allows users to schedule groups, add newgroups, delete groups, and export groups to a spreadsheet program. TheGroups screen also shows the group list with the associated airport,terminal, vehicle type, passengers, and pickup time, date and locationfor each group. After updating the groups and returning to the event,the new prices and costs are clearly shown.

The Group screens contain fields for “Group Name,” “Customer Name,”“Event Name,” “Airport,” “Terminal,” “Pickup Date,” “Pickup Time,”“Group Time,” “Window,” “Vehicle Type,” “Requested Chauffeur,” “MaxCapacity,” (maximum number of passengers per vehicle) “RemainingCapacity,” (remaining number of passengers per vehicle) “Price,”“Distance,” “Time,” and “Directions” (for airport terminal for eachgroup). In FIG. 7H, the screen shows a terminal map 730 of the Ft.Lauderdale Hollywood International Airport, for example.

FIG. 7I shows the “Event Staff” screen. This screen allows a user tocreate a profile for a staff member of an event. It provides fields forentering the event name, customer name, location, meeting point, workertype, cost, starting and ending dates and times, along with specialrequirements. In this example, the event name is “Tristar MedicalManifest,” the customer name is “Tristar Worldwide,” the worker typechosen is “Driver Greet” and the start time is 1 PM. This screen alsoprovides links to update the worker or go back to the event.

The system also offers an “Admin User List” screen for providing a userwith administrative functions. If the user is an administrator, he orshe can edit, create, or remove accounts. In one embodiment, the userlist shows “UserName,” “Email,” “Password,” “IsLockedOut,” and“LastLoginDate” fields for information particular to each user. Eachfield is editable via an edit button. The “IsLockedOut” field showswhether or not a user is able to access the event management system.

The system may also produce an “Admin User Detail” screen for providinga user with the administrative functions of editing a user and assigninga new account to the user. In an embodiment, the screen has a user namefield, and account field, an email field, and fields for enteringpasswords. The screen also provides links to update the user and to goback to the user list. In this example, the fields are filled in.

The system may produce an “Admin Airport List” screen for providing auser with a view of the Airport List. In this example, the airport listhas an airport code that corresponds to an airport name. The codes andnames can be edited by a link to an editing screen. In this example,buttons leading to the editing screen are provided on the Airport List.

The system may further produce an “Admin Airport Detail” screen forproviding a user with the ability to edit an airport. In this example,there are fields for entering an airport name and a corresponding code.There is also a section on this screen for “Terminals.” Each terminalcan be edited. In this example, the terminal names have each have editbuttons that lead to a terminal editing page. The screen includes linksto add terminals or delete terminals. The screen also provides links toupdate the airport and go back to the Airport List.

The system may further produce an “Admin Terminal Detail” screen forproviding the user with an interface by which to edit a terminal. Thescreen has a field for entering the terminal name along with a list ofairlines to select for each terminal. In this example, the airlines haveboxes that can be selected or deselected as the user edits a terminal. Amap of the airport for the terminal is also provided on the screen.

The system may produce an “Admin Airline List” screen for viewing theAirline List. The screen also provides links to add a new airline ordelete an airline. Each airline is shown with a box that can be selectedor deselected. The screen has columns for the name of the airlines andfor a corresponding code. In this example, a user can edit each airlinecan be edited by selecting an edit button.

The system may further produce an “Admin Airline Detail” screen forproviding a user with the ability to edit an airline. In this example,the screen provides fields for entering the name of the airline, code ofthe airline, and designating whether a flight is international ordomestic. The screen also provides links to update an airline and to goback to the Airline List.

The embodiments described above are created for the Event Management andGround Transportation industry, but the open architecture andextensible, rules-based design of the workflow engine allow it to beutilized in other industries or markets that can benefit from theautomated, optimized grouping, sorting and routing of entities (be theyhuman travelers, crates of produce, boxes of equipment, etc.) that aredistributed via ground transport vehicles.

The terms and descriptions used herein are set forth by way ofillustration only and are not meant as limitations. Those skilled in theart will recognize that many variations are possible within the spiritand scope of the invention as defined in the following claims, and theirequivalents, in which all terms are to be understood in their broadestpossible sense unless otherwise indicated.

1. A computerized method for organizing flight information forpassengers attending an event, comprising: receiving, in a computer, afile containing passenger information concerning one or more passengers;scanning the file for headers specifying required information, therequired information includes passenger name and flight information; ifheaders specifying required information are identified, allowing manualediting of the passenger information, and storing passenger informationin a memory, if one or more headers specifying required information arenot identified, providing a user interface on a computer display thatallows a user to manually enter required header information, processingthe file, allowing manual editing of the passenger information, andstoring the passenger information in the memory; and validating flightinformation in the stored passenger information.
 2. The method of claim1, wherein the flight information comprises information concerning twoor more of the following: arrival date, arrival time, arrival airport,arrival airline, arrival flight number, departure date, departure time,departure airport, departure airline and departure flight number.
 3. Themethod of claim 1, wherein the receiving file step comprises receiving apre-existing file stored in a computer readable storage medium.
 4. Themethod of claim 1, further comprising: creating a distribution list ofpassengers attending the event; sending a passenger information templateto each passengers on the distribution list.
 5. The method of claim 1,wherein the validating flight information step comprises: confirmingthat a flight number is in agreement with the corresponding airlinelisted in the passenger information; confirming that a flight number isin agreement with the corresponding arrival or departure time listed inthe passenger information; and determining airport terminal informationbased on flight number and airline.
 6. The method of claim 5, whereinthe airport terminal information is determined based on historicinformation.
 7. The method of claim 1, wherein the validating flightinformation step further comprises: automatically updating the flightinformation previously validated.
 8. The method of claim 1, wherein theuser interface allows the user to assign a pre-determined header to adata column in the file.
 9. The method of claim 1, wherein the userinterface allows the user to provide required header information bylinking a data column to a pre-determined tab on the user interface. 10.A system for organizing flight information for passengers attending anevent, comprising: a memory; a computer display; a synchronizationcomponent that maps passenger information from a user format into anapplication specific format and stores mapped passenger information inthe memory, wherein said synchronization component scans passengerinformation in a user format, identifies headers specifying requiredinformation, and assigns headers to required information that does nothave a header, and wherein the required information includes passengername and flight information; a flight validation component thatvalidates flight information in the stored passenger information, and adata visualization component that generates a visual display ofpassenger information.
 11. The system of claim 10, wherein the flightinformation comprises information concerning two or more of thefollowing arrival date, arrival time, arrival airport, arrival airline,arrival flight number, departure date, departure time, departureairport, departure airline and departure flight number.
 12. The systemof claim 10, further comprising a passenger information collectioncomponent that creates a distribution list of passengers attending theevent and sends a passenger information request to each passengers onthe distribution list, wherein a passenger may respond to the passengerinformation request by providing information in a passenger informationfile attached to the request and send the passenger information file tothe passenger information collection component.
 13. The system of claim12, wherein the passenger information collection component furtherprovides a user interface that allows a user to monitor passengerresponses to the passenger information request.
 14. The system of claim10, wherein the flight validation component performs one or more of thefollowing: confirming that a flight number is in agreement with thecorresponding airline listed in the passenger information; confirmingthat a flight number is in agreement with the corresponding arrival ordeparture time listed in the passenger information; and determiningairport terminal information based on flight number and airline.
 15. Thesystem of claim 14, wherein the airport terminal information isdetermined based on historic information.
 16. The system of claim 10,wherein the flight validation component further comprises an updatecomponent wherein the flight information is automatically updated. 17.The system of claim 10, wherein the synchronization component comprisesone of: an auto guessing component to filing missing data in passengerinformation, a faulty data detection and correction component thatdetects and corrects faulty data in passenger information, and a genderidentification component that identifies passenger gender.
 18. Thesystem of claim 17, wherein the faulty data detection and correctioncomponent comprises a linguistic component to identify and offer optionsto correct errors in the data.
 19. The system of claim 10 wherein thesynchronization component performs one or more of the following:converting airline names to airline codes; and mapping a passenger type,wherein one of the passengers types is VIP.
 20. A computer programproduct for organizing flight information for passengers attending anevent, comprising: a computer readable medium and computer readable codeembodied on the computer readable medium for organizing flightinformation for passengers attending an event, the computer readablecode comprising: computer readable program code devices configured toenable a synchronization process to map passenger information from auser format into an application specific format and stores mappedpassenger information; and computer readable program code devicesconfigured to enable a process to validate flight information in storedpassenger information. wherein the synchronization process includes:scanning passenger information in the user format, identifying headersspecifying required information, and assigning headers to requiredinformation that does not have a header, and wherein the requiredinformation includes passenger name and flight information.